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Abstract 

We present several proposals for extending the Open Community Runtime (OCR) specification. The extension are identifiers with 
local validity, which use the concept of futures to provide OCR implementations more optimization opportunities, labeled GUIDs 
with creator functions, which are based on the local identifiers and allow the developer to create arrays of OCR objects that are safe 
from race conditions in case of concurrent creation of objects, a simple file 10 interface, which builds on top of the existing data 
block concepts, and finally data block partitioning, which allows better control and flexibility in situations where multiple tasks 
want to access disjoint parts of a data block. 

1 Introduction 

The Open Community Runtime specification m is still in an early stage of development. There are many opportunities 
to extend the API, in order to provide it with new functionality or to provide more efficient ways of building OCR 
applications. In the following text, we present several proposals for such extensions. The extensions have been 
implemented in the experimental OCR-Vl single-threaded OCR runtime, available here: 

http://homepage.univie.ac.at/jiri.dokulil/projects/ 

Status of the text This text describes the current state of a work-in-progress and will be updated in the future. 

2 Constraints 

In our considerations, we do not target a specific OCR implementation, but we do make some assumptions about what 
the implementation looks like. 

Messages We assume that the runtime works by sending messages between the nodes of a distributed system. A call 
to the OCR API typically translates to one or more messages, that could either be handled locally or sent to another 
node for processing. 

GUIDs The OCR specification does not prescribe how GUIDs should look like. However, we assume that a GUID 
may encode information that is not available before the call to the OCR API which creates the object identified by 
the GUID. For example, the GUID may encode the type of the object, or some of the arguments of the creation call, 
like the number of pre-slots of a task. It is therefore not possible to pre-allocate GUIDs. Furthermore, we assume that 
it may not be possible to create GUIDs locally. It may be necessary to communicate with another node in order to 
discover the actual value of the GUID. Possible examples of GUIDs under these contraints include: 

• Address of the OCR object in a global (shared) address space. 

• A pair consisting of a node identifier and sequential identifier of the object within the node. 

• A tuple consisting of a node identifier, sequential identifier, and object type (enumeration). 

• Global sequential identifier of the object, maintained by a coordinator node. 
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3 Local identifiers 


Ideally, it should be possible to process all OCR API calls (made by tasks) locally, without the need to send a message 
to a remote node and wait for the reply. With relaxed requirements for error detection, this is possible for most 
of the API calls. For example, the ocrEventSatisfy call can be handled by a message that would inform the 
event that its pre-slot has been satisfied. The call only affects the satisfied event, not the calling task. Therefore, the 
ocrEventSatisfy function can return immediately, without waiting for the message to be processed. 

Functions which create objects are an exception. They have to return the GUID of the newly created object. With 
the restrictions we have placed on the GUIDs, some implementations may need to contact another node, for example 
to get the current value of the ID sequence of the node where the object will actually be created. Once the GUID is 
determined and returned to the calling task, it may for example store the GUID in a data block, so that other tasks can 
read it and use it in further OCR API calls. However, it is also common that the GUID is only used to make several 
calls to the OCR API by the task that created the object. The GUID is not stored in any data block. A typical example 
would be when a task is created and all of its dependences are immediately defined by the creating task. 

If the GUID is not saved, it is not necessary to have a true GUID - a globally unique identifier. Therefore, an 
identifier with a local validity may be sufficient. Since the OCR abstracts nodes, the only applicable scope besides the 
global scope is a task. Therefore, the OCR call which creates an object may return a local identifier (a LID), which 
may only be used to make OCR API calls by the task that created the object. Such a LID cannot be saved to a data 
block and used by another task. 

A different view of the LIDs is to view them as futures. Instead of returning the new object’s GUID, a future is 
returned. The future may be used to make further OCR API calls, but the runtime does not yet send out messages that 
implement these calls. At some later point in time (possibly after the task has finished) the future will be resolved, 
allowing the runtime to update the messages, providing the actual GUID instead of the future. 

Consider the following example; 

void launch_task (ocrGuid_t task_template, ocrGuid_t data) 

{ 

ocrGuid_t task_lid; 

ocrEdtCreate(&task_lid,task_template,0,0,1,0,EDT_PROP_LID,NULL_GUID,0); 

ocrAddDependency(data,task_lid,0,DB_MODE_EW); 

} 


This may be implemented like this: 

1. ocrEdtCreate generates a new LID Li, sends out a message Mcreate specifying LID Li for the object. It 
immediately returns, providing Li as the task’s identifier. 

2. ocrAddDependency generates a new message with the data block’s GUID Gdata and task’s LID Li. 
It returns immediately. 

3. At any point in the future, the Mcreate message is processed. The EDT is created with GUID Gi. A new 
message M^ap is generated, describing the mapping from Li to Gi. This message is sent back to the node that 
made the original ocrEdtCreate call. 

4. Mmap is received and processed. As a result the Mdep is updated, replacing Li with Gi. Then, it is submitted 
for processing as it would be normally. 

To make the API more usable, the LID extension should not just provide extra flags for the calls of function that 
create OCR objects. It should also include at least the two following functions: 

enum ocrIdType 
{ 

OCR_ID_GUID, // ID is GUID 
OCR_ID_LID, // ID is LID 
OCR_ID_UNK, // Error, incorrect ID 

}; 

ocrIdType ocrGetldlype (ocrGuid_t id); 
u8 ocrGetGuid (ocrGuid_t* quid, ocrGuid_t sourceld) ; 
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The ocrGetGuid would be an exception to the “no blocking” rule in the OCR API. It blocks until the GUID can 
be obtained (until the Mmap message from the previous example arrives). The ocrGetIdType may be important 
for optimization of the application code. In some situations, the runtime may be able to return a real GUID, rather 
than LID, even without communication. Therefore the GUID may be returned, even if a LID was requested. This is 
not a problem, since the GUID can be used everywhere instead of a LID. But the application may be able to use the 
fact that it received a GUID, even if the LID would be sufficient for now. 

4 Labeled GUIDs 

The OCR specification draft 1.0.1 contains a proposal for labeled GUIDs. The idea is to provide a convenient way 
of managing a large number of GUIDs without the need to pass all such GUIDs from task to task. Instead, a map is 
created. The user can then obtain a GUID from the map just by providing a GUID of the map and coordinates of the 
object within the map. There are two issues connected to creation of objects in such maps. First, we assume that it 
may not be possible to create a GUID before the parameters of the creation call are known. Second, the map should 
be able to deal with concurrent requests to acquire the same object from the map. Since it should be possible to create 
and destroy objects in the map as needed, not just when the map itself is created and destroyed, the map should take 
care of all necessary synchronization and make sure that objects are created only once. 

We propose an alternative API, based on the LIDs introduced in the previous section. The purpose of the proposal 
is to provide the highest level of guarantee in the case of concurrent object creation (GUID_PROP_BLOCK in the 1.0.1 
OCR proposal), without the need to block the task’s execution. 

typedef void (*ocrCreator_t) (ocrGuid_t objectLid, u64 index, u32 paramo, u64* paramv, u32 guide, 
ocrGuid_t* guidv); 

u8 ocrMapCreate (ocrGuid_t* mapGuid, u64 size, ocrCreator_t creatorFunc, u32 paramo, u64* paramv, 
u32 guide, oorGuid_t* guidv); 
u8 oorMapDestroy (oorGuid_t mapGuid); 

u8 oorMapGet (oorGuid_t* lid, oorGuid_t mapGuid, u64 index); 


The ocrMapCreate function creates a new map, containing size objects, which are not yet initialized. The 
user specifies a creatorFunc - a creator function responsible for creation of objects in the map. The paramv and 
guidv arrays are forwarded to the creator function. Initially, the map is empty and no object is created. A task may 
then call ocrMapGet to get an object at a specified index from the map. If the object does not exist, the map calls 
the creator function and the object is created. However, this creation has to be properly synchronized by the runtime, 
to make sure that concurrent calls to ocrMapGet with the same index return the same object. At the same time, 
we would like all OCR API calls to return immediately, without any communication. Since synchronization without 
communication is not possible, we use LIDs to solve the problem. The ocrMapGet returns a LID of the object. This 
can be done locally. If two tasks make an identical ocrMapGet call, they get different LIDs, but once resolved, the 
LIDs will point to the same object (same GUID). 

The remaining issue is the inside of the creator function. We have to consider two different options. First, the 
runtime may prefer to use a sequence of consecutive GUIDs for the map. In this case, it needs to set up all GUIDs in 
the map at the time the map is created. Second, the runtime may only be able to create the GUID of an object when 
the object is created. Therefore, the GUIDs in the map are only filled as the individual objects get created. We propose 
to also use LIDs in this case. However, they serve a different purpose. When a map needs to create an object, it first 
creates a LID. The LID is then passed to the creator function, which in turn passes it to the call of the ocrXxxCreate 
function. This changes the GUID parameter of such function from out parameter to inout. We also propose to add 
a new flag to such functions, to distinguish the situation. 

Following code is an example application using our labeled GUID API to create a 2D matrix of tasks, where each 
task depends on its immediate neighbors in the up and left directions. 

void creator (ocrGuid_t objectLid, u64 index, u32, u64* paramv, u32, ocrGuid_t* guidv) { 
u64 width = paramv[0]; 
u64 height = paramv[l]; 
u64 X = index % width; 
u64 y = index / width; 
u64 params[] = { x, y }; 
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ocrGuid_t deps[] = { guidv[0], UNINITIALIZED_GUID, UNINITIALIZED_GUID }; 
if {x == 0) deps[l] = NULL_GUID; 
if {y == 0) deps[2] = NULL_GUID; 

ocrEdtCreate(&objectLid/ guidv[l], EDT_PARAM_DEF, params, EDT_PARAM_DEF, deps, EDT_PROP_MAPPED, 
NULL_GUID, 0); 

//The objectLid should now contain a valid GUID, but we don't need it here. 


struct data { 
ocrGuid_t map; 
ocrGuid_t task_template; 
u64 width; 
u64 height; 

}; 

u64 coords(data* data, u64 x, u64 y) { 
return x + y * data->width; 

} 

ocrGuid_t work(u32 paramc, u64* paramv, u32 depc, ocrEdtDep_t depv[]) { 

u64 X = paramv[0]; 
u64 y = paramv[1]; 
data* data = (data*)depv[0].ptr; 

if (x == data->width - 1 && y == data->height - 1) 

{ 

//The last item, we are done 

ocrEdtTempiateDestroy(data->task_template); 

ocrMapDestroy(data->map); 

ocrDbDestroy(depv[0].guid); 

ocrShutdown() ; 

return NULL_GUID; 

} 

//Do the work here. 

//. . - 

//Done . 

if (x < data->width - 1) { 

//Not the last column, satisfy preslot of the task to the right 
ocrGuid_t task; 

ocrMapGet(&task, data->map, coords(data, x + 1, y)); 
ocrAddDependence(NULL_GUID, task, 1, DB_DEFAULT_MODE); 

} 

if (y < data->height - 1) { 

//Not the last row, satisfy preslot of the task below 
ocrGuid_t task; 

ocrMapGet(&task, data->map, coords(data, x, y + 1)); 
ocrAddDependence(NULL_GUID, task, 2, DB_DEFAULT_MODE); 

} 

return NULL_GUID; 


ocrGuid_t mainEdt(u32 paramc, u64* paramv, u32 depc, ocrEdtDep_t depv[]) { 

ocrGuid_t db, task; 
void* ptr; 

ocrDbCreate(&db, &ptr, sizeof (data), 0, NULL_GUID, NO_ALLOC); 
data* data = (data*)ptr; 
data->width = 3; 
data->height = 3; 

ocrEdtTemplateCreate(&data->task_template, work, 2, 3); 
u64 params[] = { data->width, data->height }; 
ocrGuid_t guids[] = { db, data->task_template }; 

ocrMapCreate(&data->map, data->height * data->width, &creator, 2, params, 2, guids); 
ocrMapGet(&task, data->map, 0); 
return NULL_GUID; 
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Note on data blocks Unlike making direct calls to the ocrDbCreate function from the task, the creator-based 
API does not allow the pointer to a data block to be returned to the caller. However, if we want to deal with concurrent 
calls to ocrDbCreate, the pointer may not be returned anyway, since the call may be made on two different nodes, 
making it impossible to provide a valid pointer on both. With the creator, only a LID is returned. To access the data, a 
new task has to be created and have the LID as the data on one of its pre-slots. This gives the runtime the opportunity 
to deal with the situation. 

5 File lO 

Dealing with files is still an open question in the OCR. The traditional f open-based approach does not mix well with 
the resilience requirements of the OCR, since direct access to files allows tasks to have side effects outside of the OCR. 
To provide at least the most basic file lO, we propose to add “file-mapped data blocks”. These are data blocks whose 
contents are read from a file and then saved back to the file. The proposed API looks like this: 

u8 ocrFileOpen (ocrGuid_t* fileGuid, const char* path, const char* mode, ocrGuid_t* descriptorDb, 
u32 properties); 

u8 ocrFileRelease( ocrGuid_t fileGuid); 
ocrGuid_t ocrFileGetGuid( void* descriptor); 
u64 ocrFileGetSize (void* descriptor); 

u8 ocrFileGetChunk (ocrGuid_t* chunkDbGuid, ocrGuid_t fileGuid, u64 offset, u64 size); 


The ocrFileOpen function returns two GUIDs (the second is optional). The GUID of the file and a GUID 
which represents a data block, which contains information about the file. This data block cannot be used directly (no 
pointer is provided). This is intentional, since it may take some time to open the file and find out its properties. To use 
the information, a task needs to receive the data block via one of its pre-slots. This allows the runtime to delay the task 
until the information about the file is available. Once the task starts, it may use ocrFileGetSize to find out the 
size of the file when it was opened. The ocrFileGetGuid function is a convenience for a typical scenario, where 
one task calls ocrFileOpen and passes the descriptorDb to another task. The second task then reads the size of 
the file and creates other tasks to process it. To do that, the second tasks needs to know the GUID of the file. Without 
ocrFileGetGuid, a data block would have to be created to send the GUID from the first to the second task. 

Once a file has been opened, the ocrFileGetChunk call can be used to map a contiguous part of the file into 
a data block. If the data block (of f setH-size) extends beyond the end of the file and the file is writeable, it is 
enlarged. It is not allowed to define overlapping chunks. The runtime may decide not to write the chunk data back 
to the file if the chunk was not used in EW or RW mode by a task. However, if the block would cause the file to be 
enlarged, it has to be enlarged, even if the data is not written. 

The following example reads a file, which contains 32bit unsigned integers, multiplies each value by 2 and saves 
the updated values. Two tasks are used to perform multiplication in parallel. 

ocrGuid_t work(u32 paramo, u64* paramv, u32 depc, ocrEdtDep_t depv[]) { 

u32* data = (u32*)depv[0].ptr; 
for (std::size_t i = 0; i < paramv[0]; ++i) { 

data[i] *= 2; 

} 

ocrDbDestroy(depv[0].quid); 
return NULL_GUID; 

} 

ocrGuid_t check(u32 paramc, u64* paramv, u32 depc, ocrEdtDep_t depv[]) { 

ocrGuid_t chunkl, chunk2, workerl, worker2, worker_template, finish_template, finish_task, 
event 1, event2; 

u64 size = ocrFileGetSize(depv[0].ptr); 

ocrFileGetChunk(&chunkl, ocrFileGetGuid(depv[0].ptr), 0, size/2); 

OcrFileGetChunk(&chunk2, ocrFileGetGuid(depv[0] .ptr), size/2, size/2) ; 
ocrFileRelease(ocrFileGetGuid(depv[0].ptr)); 
ocrDbDestroy(depv[0].quid); 

ocrEdtTemplateCreate(&worker_template, work, 1, 1); 
ocrEdtTemplateCreate(&finish_template, test8_finish, 0, 2); 
u64 params[] = { (size / sizeof (u32))/2 }; 

ocrEdtCreate(&workerl, worker_template, EDT_PARAM_DEF, params, EDT_PARAM_DEF, 0, 0, NULL_GUID, 

Seventl); 
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ocrEdtCreate(&worker2, worker_template, EDT_PARAM_DEF, params, EDT_PARAM_DEF, 0, 0, NULL_GUID, 
&event2); 

ocrEdtCreate(&finish_task, finish_template, EDT_PARAM_DEF, 0, EDT_PARAM_DEF, 0, 0, NULL_GUID, 

0 ) ; 

ocrAddDependence(eventl, finish_task, 0, DB_DEFAULT_MODE); 
ocrAddDependence(event2, finish_task, 1 , DB_DEFAULT_MODE); 
ocrAddDependence(chunkl, workerl, 0, DB_M0DE_R0); 
ocrAddDependence(chunk2, worker2, 0, DB_M0DE_R0); 
ocrEdtTemplateDestroy(worker_template); 
ocrEdtTemplateDestroy(finish_template); 
return NULL_GUID; 


ocrGuid_t mainEdt(u32 paramc, u64* paramv, u32 depc, ocrEdtDep_t depv[]) { 

ocrGuid_t info, file, task, checker_template; 
ocrFileOpen (&file, ’’data.dat", "rb+", &info, 0); 
ocrEdtTemplateCreate(&checker_template, check, 0, 1); 
ocrGuid_t deps[] = { info }; 

ocrEdtCreate(Stask, checker_template, EDT_PARAM_DEF, 0, EDT_PARAM_DEF, deps, 0, NULL_GUID, 0); 
ocrEdtTemplateDestroy(checker_template); 
return NULL_GUID; 


6 Data block partitioning 

Currently, if two tasks want to modify two parts of the same data block, they both need to acquire it in RW mode. The 
OCR runtime has to assume that the tasks may also share data through the data block by reading and writing to the 
same position in the data block, a situation similar io false sharing of cache lines. It may be more efficient to explicitly 
represent the fact, that these two tasks don’t access overlapping parts of the data block. At the moment, there is no way 
of expressing this directly using the OCR API. The data block could be split into two (or more) data blocks, providing 
each of the two tasks with one smaller block. The tasks can acquire their respective data blocks in EW mode, without 
preventing parallel execution. But having the data split into two parts may be inconvenient for other parts of the code, 
where two GUIDs would have to be passed instead of one. Or it may be necessary to dynamically change the way the 
data is split into blocks. 

6.1 Higher-level model 

The ultimate goal is to have a higher-level programming model (HEP) on top of the OCR. The HEP will be responsible 
for management of the data blocks, so it may be able to create the data blocks in such a way that there is no false sharing 
of the data blocks. It may be necessary to use different partition strategies on one data block. Eor example, given a 
data block with four items A, B, C, and D we may first need partitions pi = {A, B} and p2 = {C, D}, but later 
partitions qi = {A} and q2 = {B, C, D}. There are two basic options. Eirst, creating three data blocks {bi = {A}, 
62 = {B}, and 63 = {C, D}) and providing multiple data blocks for each partition: pi = biU &2, P2 = ^3; qi = bi, 
q2 = ^<2 U 63. This complicates implementation of tasks that process the partitions, since they need to accept data that 
is split into multiple data blocks. The second option is to create new data blocks for partitions pi and p2 and then copy 
the data into two other blocks for partitions qi and 52- This requires extra memory and data movement. Due to the 
issues present in both options, it may be interesting to investigate alternatives where the partitioning is made explicit 
using the OCR API. 


6.2 Explicit DB partitioning support in the OCR API 

An alternative would be to add explicit partitioning support to the OCR: 


typedef struct { 

u64 offset; //[in] the offset of the partition within the parent block 
u64 size; //[in] size of the partition 
ocrGuid_t quid; //[out] GUID of the new data block 
} ocrDbPart_t; 

#define OCR_DB_PARTITION_STATIC ((ul6) 0x1) 

u8 ocrDbPartition (ocrGuid_t dbGuid, u32 partCount, ocrDbPart_t* partitions, u32 properties); 
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The ocrDbPartition function accepts a list of partition definitions and returns a list of GUlDs for the corre¬ 
sponding partitions. The partitions are not allowed to overlap, but there can be “holes” - sections of the data block 
that don’tbelong to any partition. Unless OCR_DB_PARTITION_STATIC is provided, ocrDbPartition can be 
used again on the same data block to create more partitions. However, no partitions (both new and old) may overlap. 
If partitioning is static, it’s not possible to use ocrDbPartition on the data block until all partitions have been 
destroyed using ocrDbDestroy. 

It is disallowed to use a partitioned data block to satisfy a pre-slot (either directly on indirectly via a dependence) 
of a task that may become runnable before all partitions have been destroyed. A more relaxed condition would be to 
allow the data block to be used this way, but the runtime may decide not to allow any task to actually acquire the data 
block until all partitions have been released. It is still not possible to pass the partitioned data block and one of its 
partitions to the same task, since that may cause a deadlock. 

It is possible to further partition data blocks acquired by partitioning. Recursive partitioning is allowed, with 
the same constraints. It is not possible to create a partition that does not represent a single contiguous block of the 
partitioned DB. So, for example, it’s not possible to create cyclic partitions. There is also no API to query the partition 
information of a data block or to check whether a data block is a regular data block, partitioned data block, or a 
partition. 

The following example demonstrates the partitioning API. It creates a data block, splits it into two partitions, 
executes a worker task on each partition, and finally uses the original data block in the final task. 

ocrGuid_t finish(u32 paramc, u64* paramv, u32 depc, ocrEdtDep_t depv[]) { 

u64 sum = 0; 

u32* data = (u32*)depv[0].ptr; 

for {std::size_t i = 0; i < 1024; ++i) sum+=data[i]; 

PRINTF {"%lu\n", sum); 
ocrDbDestroy(depv[0].quid); 
ocrShutdown(); 
return NULL_GUID; 


ocrGuid_t work(u32 paramc, u64* paramv, u32 depc, ocrEdtDep_t depv[]) { 

u32* data = (u32*)depv[0].ptr; 
for {std::size_t i = 0; i < 512; ++i) { 

data[i] *= paramv[0]; 

} 

ocrDbDestroy(depv[0].quid); 
return NULL_GUID; 


ocrGuid_t mainEdt(u32 paramc, u64* paramv, u32 depc, ocrEdtDep_t depv[]) { 

ocrGuid_t block, worker_template, workerl, workerl_event, worker2, worker2_event, 
finis h_t emplate, finis h_t ask; 
void* ptr; 

ocrDbCreate(Sblock, &ptr, 1024 *sizeof (u32), 0, NULL_GUID, NO_ALLOC); 
u32* data = (u32*)ptr; 
for {u32 i = 0; i < 1024; ++i) { 

data[i] = 1;// i + 1; 

} 

ocrDbPart_t parts[2]; 

parts[0].offset = 0; 

parts[0].size = 512 * sizeof(u32); 

parts[1] .offset = 512 * sizeof{u32); 

parts[l].size = 512 * sizeof(u32); 

ocrDbRelease(block); //could also come later, but the data is no lonqer needed 
ocrDbPartition(block, 2, parts, 0); 

ocrEdtTemplateCreate(&worker_template, work, 1, 1); 
ocrEdtTemplateCreate(&finish_template, finish, 0, 3); 
u64 paramsl[] = { 2 }; 
u64 params2[] = { 6 }; 

ocrEdtCreate(&finish_task, finish_template, EDT_PARAM_DEF, 0, EDT_PARAM_DEF, 0,0, NULL_GUID,0); 
ocrEdtCreate(&workerl, worker_template, EDT_PARAM_DEF, paramsl, EDT_PARAM_DEF, 0, 0, NULL_GUID, 
Sworkerl_event) ; 
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ocrEdtCreate(&worker2, worker_template, EDT_PARAM_DEF, params2, EDT_PARAM_DEF, 0, 0, NULL_GUID, 
&worker2_event); 

ocrEdtTemplateDestroy(worker_template); 
ocrEdtTemplateDestroy(finish_template); 
ocrAddDependence(block, finish_task, 0, DB_MODE_RO); 
ocrAddDependence(workerl_event, finish_task, 1, DB_DEFAULT_MODE); 
ocrAddDependence(worker2_event, finish_task, 2, DB_DEFAULT_MODE); 
ocrAddDependence(parts[0].quid, workerl, 0, DB_MODE_EW); 
ocrAddDependence(parts[1].quid, worker2, 0, DB_MODE_EW); 
return NULL_GUID; 


6.3 Paritioning as an optimization of data block copying (using ocrDbCopy) 

The 0.9 version of the OCR proposal contained a function to copy data blocks in an asynchronous way: 

u8 ocrDbCopy (ocrGuid_t destination, u64 destinationOffset, ocrGuid_t source, u64 sourceOffset, 
u64 size, u64 copyType, ocrGuid_t * completionEvt); 


This could be used, for example by the higher-level programming model, to copy the original data block into 
several data blocks that represent the partitions. In certain circumstances (if the destinationOf f set is 0 and 
size covers the whole destination data block), the runtime could view it as creation of a partition, as if the special 
API from the previous section was used. It could even skip actually copying the memory, reusing the source buffer, 
with copy-on-write semantics. That could still mean that some of the data will be copied, but it still gives the runtime 
some room for optimizations. Furthermore, the copyType argument could be used to indicate that the source data 
block will not be used by any task and the data will be copied back before the destination block is destroyed, providing 
functionality similar to ocrDbPartition, with partitioning that is potentially zero-copy. Naturally, it is also not 
possible to use the partitioned data block before partitions have been copied back. The user is responsible for ensuring 
that this rule is observed. 

Following example demonstrates how to achieve partitioning similar to the example of the explicit API: 

ocrGuid_t finish(u32 paramc, u64* paramv, u32 depc, ocrEdtDep_t depv[]) { 

ocrDbDestroy(depv[3].quid); //destroy the "params" data block 
u 6 4 s um = 0; 

u32* data = (u32*)depv[0].ptr; 

for {std::size_t i = 0; i < 1024; ++i) { 

( 

sum += data[i]; 

} 

PRINTF {"%lu\n", sum); 
ocrDbDestroy(depv[0].quid); 
ocrShutdown(); 
return NULL_GUID; 


ocrGuid_t work(u32 paramc, u64* paramv, u32 depc, ocrEdtDep_t depv[]) { 

u32* data = (u32*)depv[0].ptr; 
ocrGuid_t* quids = (ocrGuid_t* )depv[1] .ptr; 
for {std::size_t i = 0; i < 512; ++i) { 

data[i] *= paramv[0]; 

} 

ocrDbRelease(depv[0].quid); 
ocrGuid_t event; 

ocrDbCopy(quids[1] , paramv[2] * sizeof(u32), depv[0].quid, 0, 512 * sizeof(u32), 

DB_COPY_PARTITION_BACK, Sevent);/ /DB_COPY_PARTITION_BACK entails destruction of the source 
ocrAddDependence(event, quids[0], paramv[l], DB_MODE_NULL); 
return NULL_GUID; 


ocrGuid_t mainEdt(u32 paramc, u64* paramv, u32 depc, ocrEdtDep_t depv[]) { 

ocrGuid_t block, params, worker_template, workerl, worker2, finish_template, finish_task, 
chunkl, chunk2, chunkl_copied, chunk2_copied; 














void *ptr, *params_ptr; 

ocrDbCreate(Sblock, &ptr, 1024 * sizeof(u32), 0, NULL_GUID, NO_ALLOC); 
u32* data = (u32*)ptr; 
for {u32 i = 0; i < 1024; ++i) { 

data[i] = 1;// i + 1; 


ocrDbRelease(block); //could also come later, but the data is no longer needed 
ocrDbCreate(&params, &params_ptr, 2 * sizeof (ocrGuid_t) , 0, NULL_GUID, NO_ALLOC); 
ocrDbCreate(Schunkl, &ptr, 512 * sizeof (u32), DB_PROP_NO_ACQUIRE, NULL_GUID, NO_ALLOC); //with 
DB_PROP_NO_ACQUIRE, the runtime may decide not to allocate any memory at this time 
ocrDbCreate(&chunk2, &ptr, 512 * sizeof (u32), DB_PROP_NO_ACQUIRE, NULL_GUID, NO_ALLOC); 
ocrDbCopy (chunkl, 0, block, 0, 512 * sizeof (u32), DB_COPY_PARTITION, &:Chunkl_copied) ; 

ocrDbCopy(chunk2, 0, block, 512 * sizeof (u32), 512 * sizeof {u32), DB_COPY_PARTITION, S 

chunk2_copied); 

ocrEdtTemplateCreate(&worker_template, work, 3, 2); 
ocrEdtTemplateCreate(&finish_template, finish, 0, 4); 
u64 paramsl[] = { 2, 1, 0 } ; 

u64 params2[] = { 6, 2, 512 } ; 

ocrEdtCreate(&finish_task, finish_template, EDT_PARAM_DEF, 0, EDT_PARAM_DEF, 0, 

0 ) ; 

ocrEdtCreate(&workerl, worker_template, EDT_PARAM_DEF, paramsl, EDT_PARAM_DEF, 

0 ) ; 

ocrEdtCreate(&worker2, worker_template, EDT_PARAM_DEF, params2, EDT_PARAM_DEF, 

0 ) ; 

( (ocrGuid_t* )params_ptr)[0] = finish_task; 

( (ocrGuid_t*) params_ptr)[1] = block; 
ocrDbRelease(params) ; 

ocrEdtTemplateDestroy(worker_template); 
ocrEdtTemplateDestroy(finish_template); 
ocrAddDependence(block, finish_task, 0, DB_MODE_RO); 
ocrAddDependence(params, finish_task, 3, DB_MODE_RO) ; 
ocrAddDependence(chunkl_copied, workerl, 0, DB_MODE_EW); 
ocrAddDependence(chunk2_copied, worker2, 0, DB_MODE_EW); 
ocrAddDependence(params, workerl, 1, DB_M0DE_C0NST); 
ocrAddDependence(params, worker2, 1, DB_MODE_CONST); 
return NULL_GUID; 


0, NULL_GUID, 

0, 0, NULL_GUID, 
0, 0, NULL_GUID, 


Since the data block is created with DB_PROP_NO_ACQUIRE and then filled by calling ocrDbCopy with 
DB_COPY_PARTITION, the runtime knows not to allocate memory for the data block and also that the block is 
in fact a partition of another block. As a result, it can reuse the memory of the partitioned block. On the other hand, if 
an OCR implementation does not want to provide partitioning, it only needs to ignore DB_COPY_PARTITION and 
extend ocrDbCopy to release the source data block when DB_COPY_PARTITION_BACK is used. This makes the 
extension relatively cheap to implement if the zero-copy functionality is not desired. 
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